With the advent of pervasive computing devices such as hand-held or palm-sized computing devices, and operating systems (e.g., Microsoft PocketPC®) which offer a significant subset of the familiar desktop based computing environment (e.g., Windows 2000®), there is a tendency to make familiar applications available on the pervasive platform.
A good example is the ‘POP3’ (Post Office Protocol version 3) mail client (such as found, e.g., in common applications such as Outlook Express™, or Netscape Messenger™), which allows email to be sent and received by the palmtop device. The problem with this is that the present applications are not really suitable to work in the unique connectivity environment of pervasive devices. This is because pervasive devices' unique connectivity environment lacks a ubiquitous wireless network with broad coverage which allows an “always connected” mode of operation. Instead, the pervasive devices connect at infrequent intervals to perform “online tasks”, and are disconnected for the rest of the time.
Asynchronous messaging products such as IBM's ‘WebSphere MQ’® and ‘WebSphere MQ Everyplace’® seek to insulate application programmers from having to worry about whether they are connected or not at any given time by offering a queuing mechanism which will take the message from the application (so the application can forget about it), and hold it until a later time when connectivity is available and the message can be delivered to its destination on a remote machine.
Unfortunately, the writers of most “user” applications (e.g., POP3 and ‘SMTP’ mail clients, ftp clients, Web browsers, etc.) did not have this model in mind when they wrote the applications, since they assume the existence of a client-server connection at the time the application performs its sending or receiving function.
Currently there are two approaches in use: (1) the pervasive device has to be connected to the network when the command is issued in the client application which causes it to make a client-server connection to a remote server, or (2) a custom application has to be written, which makes explicit use of an asynchronous messaging system and have the flow of interactions with the user redesigned to fit into an asynchronous model where the reply is not likely to come back for a significant time, i.e., make it into a “batch submission” system.
Neither of these approaches is satisfactory in the pervasive device environment with today's “not always connected” networking infrastructure.
A need therefore exists for a method and arrangement for impermanent connectivity wherein the abovementioned disadvantage(s) may be alleviated.